The following abbreviations are utilized herein:    ACK acknowledgement (acknowledgement message)    AP access point    ATIM announcement traffic indication message    BSS basic service set    DTIM delivery traffic indication message    EDCA enhanced distributed channel access    GAS generic advertisement service    IBSS independent basic service set    IEEE institute of electrical and electronics engineers    MAC medium access control (layer 2, L2)    MAP mesh access point    MDA mesh deterministic access    MP mesh point    MSDU MAC service data unit    PS power save    STA station    TBTT target beacon transmission time    TIM traffic indication message    WLAN wireless local area network
Local and larger metropolitan wireless area networks are becoming of increasing interest, particularly in view of the adoption of Wi-Fi capability in handheld devices. When within range of a wireless network, Wi-Fi capability gives a hand-held device, e.g., a cell phone, the ability to connect to the internet through a local hot spot, instead of through a wireless telephone connection with a cellular carrier. This often results in faster performance, as transactions necessary to service, e.g., browsing activity, are streamlined and simpler in a Wi-Fi connection when compared to a connection through an active telephone connection with a cellular carrier.
These advances raise issues of how best to implement network access and how to coordinate the activities of devices facilitating network access. In one possible implementation, the coordination of devices within radio range is achieved by the exchange of beacon frames. Periodic beacon transmission enables device discovery, supports dynamic network organization, and provides support for mobility.
In proposed wireless local area network (WLAN) deployments without mesh services, stations (STAs) must associate with an access point in order to gain access to the network. These stations are dependent on the access point (AP) with which they are associated to communicate. An example of a nonmesh WLAN deployment model 100 and device classes 120, 130 are depicted in FIG. 1. Stations 130 are connected through access points 120 to external network 110.
Many WLAN devices can benefit from support for more flexible wireless connectivity. Functionally, the distribution system of an access point can be replaced with wireless links or multihop paths between multiple access points. Devices traditionally categorized as clients can benefit from the ability to establish peer-to-peer wireless links with neighboring clients and access points in a mesh network.
An example of a mesh network 200 is depicted in FIG. 2. Mesh points (MPs) 224 are entities that support mesh services, i.e., they participate in the formation and operation of the mesh network. A mesh point 224 may be collocated with one or more other entities (e.g., an access point 232, portal 222, etc.). The configuration of a mesh point 224 that is collocated with an access point 232 is referred to as a mesh access point (MAP) 230. Such a configuration allows a single entity to logically provide both mesh functionalities and access point functionalities simultaneously. Stations 240 associate with access points to gain access to the network 210. Only mesh points participate in mesh functionalities such as path selection and forwarding, etc. Mesh portals (MPPs) 220 comprised of a mesh point 224 and portal 220 interface the network to other LAN segments.
In one exemplary implementation, a “Mesh network model” is envisioned as an IEEE 802 LAN comprised of IEEE 802.11 links and control elements to forward frames among the network members. Effectively, this means that a mesh network appears functionally equivalent to a broadcast ethernet from the perspective of other networks and higher layer protocols. Thus, it normally appears as if all MPs in a mesh are directly connected to the link layer. This functionality is transparent to higher layer protocols. Reference in this regard can be made to FIG. 3A. Here a mesh service data unit (MSDU) is transmitted in network 300 from MSDU source 310 to MSDU destination 320 over a multi-hop network of mesh points 330. It should be noted that while this figure shows the forwarding of data over multiple hops, there may also be direct data transfer over a single hop, such as is shown in ad-hoc 1-hop networking model 350 of FIG. 3B, wherein the source and destination of the MSDUs are within a one-hop neighborhood through mesh points 360, and where no forwarding, routing or link metric need be used.
In an infrastructure basic service set (BSS) stations rely on the access point for power saving. A station informs the access point before switching from active to power save mode. If any station in BSS operates in power save mode the access point buffers multicast and broadcast traffic and delivers the traffic after the delivery traffic indication message (DTIM) period. The DTIM interval is a multiple of beacon periods. For unicast traffic that is buffered in the access point, stations periodically need to wake up to receive the traffic indication map (TIM) that is present in all beacon frames. Having learned from a beacon frame that unicast traffic directed to the station is pending, a station sends out a power save (PS) poll frame to request the traffic's delivery from the AP.
In an independent basic service set (IBSS) mode, also known as ad-hoc, the basic approach is similar to the infrastructure BSS case in that the stations are synchronized, and multicast traffic and the traffic that is to be transmitted to a power-conserving station are first announced during a period when all stations are awake. The announcement is performed via a message sent in an announcement traffic indication message (ATIM) window. A station in the power save mode shall listen for these announcements to determine if it needs to remain in the awake state. The presence of the ATIM window in the IBSS indicates if the station may use the power save mode. To maintain correct information on the power save state of other stations in an IBSS, a station needs to remain awake during the ATIM window. At other times the station may enter the doze state.
For example, in one possible implementation two different power states may be specified. In the awake state the mesh point is able to transmit or receive frames and is fully powered, while in the doze state the mesh point is not able to transmit or receive and consumes very low power. The transitions between these two power states are determined by the mesh point power management modes, i.e., an active mode where the mesh point shall be in the awake state all the time and the power save mode where the mesh point alternates between awake and doze states. There may be further power save modes, for example, a deep sleep mode where the mesh point transmits its delivery traffic indication message (DTIM) beacon and stays active during its own awake window after its DTIM beacon. Another mode may be a light sleep mode. If a peer mesh point operates in this mode the mesh point transmits its traffic indication map (TIM) and DTIM beacons and stays awake during its awake window after its DTIM beacon and after its TIM beacon with the awake window information element. The mesh point listens to all the beacons from all peer mesh points to which it has indicated to operate in light sleep mode.
Further rules for how the communication to and from the mesh point in power save can be triggered are defined. The mesh point which transmitted the beacon may operate in the awake state until it has received a trigger frame from all peer mesh points which have indicated to operate in a power save mode where they are listening to beacons (e.g. light sleep mode), and the beaconing mesh point has indicated availability of buffered traffic for the peer mesh points in its beacon frame. However, the nature of the radio environment and protocol is such that the mesh point cannot be sure that all peer mesh points which have indicated to operate in such a power save mode have received the beacon. Thus, if the peer mesh point does not receive the beacon correctly, the mesh point does not know that it should transmit a trigger frame to the beaconing mesh point. In this case the beaconing mesh point must stay in the awake state until it receives a frame from the peer mesh point which can be interpreted as a trigger frame, or indicates in its own consecutive beacon that it does not have any frames to transmit.
The operation in deep sleep mode may be defined in such a way so that the mesh point in deep sleep is only transmitting its own DTIM beacon and the mesh point is not mandated to listen for any peer mesh point beacons. In practice even the deep sleep mode mesh point may have occasional reasons to transmit some frames to peer mesh point for example for routing purposes or even link maintenance purposes.
With this discussion as background, problems have been encountered in frame exchange over multi-hop networks (e.g., like the previously-described networks). One problem that has been encountered is how to guarantee end-to-end (E2E) quality of service (QoS) if mesh points involved in the transmission are in a power save mode.
Accordingly, those skilled in the art seek methods and apparatus that overcome the foregoing and other limitations of the prior art.